Dans la série « cultivons-nous, même avec un peu de retard par rapport à leur parution, grâce aux rapports de nos amies les sociétés de sécurité informatique », nous allons regarder aujourd’hui le travail de Synopsys, dont une des spécialités est l’analyse de code.

Depuis une dizaine d’années, leurs spécialistes se penchent sur le code open source. S’il faut comme toujours garder une certaine distance avec leurs propos car il y a toujours une composante marketing et avant-vente, les constats de ces sociétés bien établies sont toujours plein d’enseignements.

La source...

Leur document OSSRA (Open Source Security and Risk Analysis) de 2024 utilise les données anonymisées de leur produit Synopsys Black Duck Audit Services, qui a analysé en 2023 plus de 1 000 bases de code, ou codebases (chez leurs clients) dans 17 secteurs d’activité. Par base de code, on entend l’ensemble de toutes les sources logicielles nécessaires à la construction d’un logiciel final. Synopsys nous a précisé que ces ressources vont du fichier pom.xml jusqu’aux .dll, en passant par des fichiers source.

Point intéressant, cet outil ne se contente pas de regarder les vulnérabilités logicielles, mais aborde aussi les aspects juridiques (licences) et qualité de code (SAST ou Static application security testing et autres). Du côté open source, ils annoncent surveiller plusieurs millions de composants.

...et l’open source

Commençons par une demi-surprise : 96 % des bases de code utilisent de l’open source. Rien d’exceptionnel cependant, nous constatons tous la prédominance de ce mode de distribution bien utile pour réutiliser des composants rapidement, et ainsi ne pas réinventer la roue. Il est plus que répandu : il est incontournable.

Or, rien que du côté de la gestion des licences, on se retrouve déjà avec des problèmes : 53 % des codebases contiennent des conflits. Cela n’est pas si anodin que cela ; pour comprendre, voici quelques exemples :

• GPLv2 et GPLv3 ne sont pas directement compatibles : si un projet a été distribué sous GPLv2 sans mention de compatibilité avec les versions futures, il ne peut pas passer sous GPLv3 sans l'accord de tous les contributeurs : imaginez le bazar !
• La GPLv2 est incompatible avec certaines autres licences comme Apache 2.0. Ainsi, un projet peut combiner des licences Apache 2.0 et GPLv3, mais il n’est pas autorisé d’avoir Apache 2.0 et GPLv2.
• Si la licence BSD permet de passer facilement à une redistribution propriétaire, la GPL impose que tout ce qui en est dérivé soit distribué en GPL.

Bien que cela soit souvent vu comme anecdotique du point de vue du développeur, le choix de la licence est souvent structurant et ne peut pas être modifié facilement !

De vieilles versions, et donc de vieilles failles qui trainent

Moins reluisant : dans 84 % des cas, le code open source comportait des vulnérabilités dont la moyenne d’âge était de 2,8 années. Dans 14 % des cas, il existe même des vulnérabilités ayant plus de dix ans. L’explication est assez simple : 91 % des composants open source trouvés ont au moins 10 versions de retard par rapport à leur version courante.

Les logiciels open source n’échappent pas au besoin de suivi et de mise à jour : il ne suffit pas de corriger les vulnérabilités, il faut intégrer ces corrections dans votre chaîne logicielle (de plus en plus complexe, par ailleurs) et gérer la dette technique, ce qui est d’autant plus difficile que la moitié des applications examinées utilisent plus de 500 composants.

Et encore, il faut que ces vulnérabilités soient corrigées un jour, car presque la moitié des composants inclus dans les codebases examinés ne montraient aucun signe de développement actif depuis deux ans ou plus. Tout le monde n’a pas la communauté de jQuery ou de React. Synopsys appelle même ce type de code « zombie » (mort-vivant).

Qui paye ses dettes (techniques) s’enrichit

En conclusion, on peut retenir que le phénomène open source, bien qu’établi depuis longtemps dans nos usines de production logicielles (à toute échelle, du développeur isolé aux multinationales), n’est que rarement bien appréhendé et bien géré par les équipes de développement.

La solution n’est ni simple ni monolithique : il faut combiner des outils d’analyse des licences, des outils de nomenclature logicielle (souvent appelés SBOM, recensant les composants utilisés dans vos applications), des outils d’analyse de code (de type SAST), mais aussi des outils d’automatisation de tests pour éviter les régressions lors d’une mise à jour des composants, etc.

Black Duck de Synopsys dont nous avons cité l’étude n’est pas le seul produit sur le marché, il y a aussi FOSSA, Mend, Snyk, ainsi que des produits (ou sous-produits) inclus dans des suites telles que Falcon de CrowdStrike.

Mais l’outillage ne fera rien sans une rigueur et une régularité dans l’examen et les mises à jour de vos composants. Même si les développeurs réagissent vite, les utilisateurs des briques open source un peu moins : la version 1 de log4j datant de 2015 était encore utilisée lors de l’apparition de la faille de 2021. Faites le calcul…

Et au risque de relancer une guerre de trolls en commentaires, l’open source n’est ni plus sécurisé ni moins sécurisé que du code propriétaire : les risques induits sont parfois similaires, mais souvent à traiter plus spécifiquement.